Support investigated and resolved tenant, product-environment, and per-user permission mismatches across Cloudinary instances. Actions that restored access included: identifying whether assets lived in the iugroup or iubh Cloudinary instance and re-granting access in the correct tenant/instance; sharing the exact requested folders with users; upgrading folder permissions to "can edit," which restored the Cloudinary UI "Replace" option; and coordinating with the CMS manager to confirm and grant access to named folders (for example GLOBAL). Where Storyblok or other tools referenced a specific Cloudinary instance, the instance linkage was verified and corrected so users saw the expected media-library assets.

Access problems were resolved by provisioning or enabling Okta-backed Cloudinary accounts and confirming SSO login. Support added users to the correct Okta/SSO groups and granted the requested space- or folder-level permissions (examples: DACH, international, iu.org, storyblok libraries) so users could upload and manage assets. Pending-invite cases were resolved by confirming invite acceptance and adding required library-group membership for space access. Role and permission updates were applied when feature visibility was restricted (for example, roles were changed to enable access to Cloudinary Analytics and video analytics). Administrative license seats were freed or activated when seat limits blocked provisioning, and approval workflows (Automation for Jira approver reviews) were used when required. In cases where an existing standalone Cloudinary account blocked joining the organization, support identified the conflict and required the user to remove the standalone account or engage Cloudinary Support before adding the user to the IU account; after that, the org-backed account was created and login details were provided. Some requests (for example, student accounts) were determined to be outside the supported entitlement and were closed as not supported. Investigation also confirmed the Cloudinary Portals capability was not enabled on some accounts; Portals was an add-on on certain Enterprise plans (Assets and Programmable Media) that required activation and pricing coordination through the Cloudinary Customer Success Manager.

Support provisioned requested cloud-hosted developer resources, processed subscription changes, and configured access roles across multiple platforms. Actions taken included: creating Hugging Face Spaces under the IU organization and delivering space URLs; creating numerous Supabase projects in IU teams on micro (commonly $10/month), small and medium compute tiers, fulfilling explicit data-residency requests (for example, projects placed in Germany), and recording GDPR data types where applicable. Support assigned Owner/Admin/Write/User roles and sent access invitations after approvals were recorded through Automation-for-Jira (approver records such as markus.traut@iu.org were tracked). Example project work included creating aia-lovable-template and aia-application-portal-dev (owner and admin assignments applied), provisioning aia-assisted-grading on a small plan, and rolling out MI_Changelog_Prod with German data residency. When requesters asked to connect external integrations or requested database credentials, projects were created and role assignments were applied as requested. Billing and cost tracking actions included associating resources with cost centers (for example CC13140) and purchasing subscriptions when required: an Xcode Cloud plan was purchased (100 hours, US$49.99/month) to restore pipeline capacity; a Meilisearch Pro SaaS subscription was approved and purchased (Pro plan ~US$300/month with included search/document quotas, priority support, 30-day analytics retention). Infrastructure provisioning included creating a Windows Server VM on Equinix Metal Managed to the requested specification (latest Windows Server, 4 vCPUs ≥2 GHz, 8 GB RAM, 50 GB disk) and assigning the final VM name. For performance or capacity requests affecting services not owned by central IT (for example a slow online-exams system), support identified the owning team and redirected the requester to the responsible internal unit (E-Assessment/Examinations office) rather than changing resources directly.

The SMTP user was created in the correct AWS SES region corresponding to the SES account (eu-central-1 rather than us-east-1), and the new credentials were stored in 1Password. Allowed sender addresses were configured for the account and a shared mailbox was created and access granted where required, resolving the SMTP authentication failures.

Identified and decommissioned unused compute and storage resources across multiple providers. Powered-off, test, or otherwise unused VMs and dedicated servers were removed or reclassified according to stakeholder confirmation; when stakeholders revoked deletion, VMs were retained in their existing (powered-off) state. Disks that blocked operations were converted to lower-cost/compatible tiers or detached when necessary; in one Equinix Metal Managed case a disk-related blockage prevented vApp creation and the VM remained un-migrated after the blocking disk was addressed. For storage-specific resources (for example Hetzner StorageBox) and dedicated servers, contents were reviewed and final backups were taken and preserved; cancellations were scheduled for agreed dates and retention windows were applied where requested. Deletions were executed on scheduled dates and tickets were closed after the agreed retention/cancellation actions completed.

Support confirmed the device was present in Jamf PreStage (registration timing can affect OOBE behavior). The user proceeded by selecting the "Set up as a new device" option shown in the OOBE; the MacBook completed setup normally and enrolled as expected once registration and PreStage provisioning were in place.

Support had users download the ZIP from the Google Drive viewer (Download button), perform an antivirus scan on the downloaded archive, and extract or move the resulting folder to the specified local Windows path. This restored access to the contained documents on the user’s desktop environment.

Root cause was identified as a widespread Cloudflare service outage that triggered challenge and rate-limit responses for the user’s IP. The support response communicated that the Cloudflare disruption caused the access blocks and that no local remediation was effective; normal access returned after Cloudflare’s service was restored.

A Google Workspace administrator used the admin restore capability to recover the deleted spreadsheet and returned it to the user’s Drive, restoring access to the original file.

Access failures were resolved by addressing identity and authentication state. For Develop Cloud cases, access was restored after the user re-authenticated (signed out and signed back in) and the user’s IU address was corrected. For Google Cloud Platform cases where an IU email had been previously used for a private Google account and Google required migration to a private Gmail address after IU reclaimed the address, access was restored by an administrator-initiated password reset; the user then logged in with the new password and regained access to the GCP project.

All three VMs were restarted but the C: drive remained full on two VMs; investigation found >70 GB stored in c:\users\omm-uipath-prod\.nuget. The incident was escalated to the OMM service provider to clear the .nuget folder and to investigate the underlying cause of the recurring disk growth.

Services were temporarily failed over to two alternative VMs to maintain continuity. An engineer restored the unresponsive VM (service/instance recovery) so it became reachable again, and the vendor confirmed the system state. Investigation of monitoring and VM logs produced no conclusive root cause entries before the restoration.

Infrastructure initiated and completed the registrar transfer process for both domains. The .de domain finished first and the .com domain completed subsequently; both domains became managed on the target platform and DNS configuration remained available in Route53 during/after the transfers.

Vendor pricing and discount options were obtained and vendor contacts engaged to negotiate terms. The request included a planned migration from AWS MWAA to Astronomer’s pay-as-you-go "Team" plan driven by MWAA limitations (outdated Airflow versions, delayed patches, weak SLAs). During procurement and onboarding, account provisioning automation failed and required manual user additions, SAML/SSO domain verification remained pending, and legal/privacy teams raised outstanding DPA questions. The procurement request remained pending sign-off from approvers and commercial review; purchase and deployment did not proceed while those approvals and legal items were unresolved.

The IU SAFE Portal application was used: the requester authenticated with their Microsoft/Okta IU account and shared the large macro-containing files via the SAFE app, enabling external collaborators to receive access without typical email or Teams limitations.

All requesters cleared site-level caches they controlled, and then Cloudflare was used to purge the CDN cache for the affected path/assets (English site path). After the Cloudflare cache purge, the branding updates appeared without requiring query-string cache bypasses.

Support was escalated to Equinix after the provided manual migration steps did not resolve the issue. An Equinix engineer performed a manual disk move of the named disk on the provider side. Once the named disk was moved, the VM migration completed successfully and the ticket was closed.